Doc. Ref. API 
Appl. No. 09/904,541 



(19) 



Europaisches Patentamt 
European Patent Office 
Office europeen des brevets 



(12) 



(43) Date of publication: 

21.06.2000 Bulletin 2000/25 



(11) EP 1 011 043 A2 

EUROPEAN PATENT APPLICATION 

(51) intci7: G 06 F 9/445 



(21) Application number: 99309811.0 

(22) Date of filing: 07.12.1999 



(84) Designated Contracting States: 


(72) Inventor: Holiday, Matthew R., Jr. 


AT BE CH CY DE DK ES Ft PR GB GR IE IT LI LU 


Collin, Texas 75002 (US) 


MC NL PT SE 




Designated Extension States: 


(74) Representative: Dearling, Bruce Clive et at 


AL LT LV MK RO SI 


Hepworth Lawrence Bryer & Bizley, 




Merlin House, 


(30) Priority: 14.12.1998 US 211209 


Falconry Court, 




Bakers Lane 


(71) Applicant: NORTEL NETWORKS CORPORATION 


Epping, Essex CM16 5DQ (GB) 


Montreal, Quebec H2Y 3Y4 (OA) 





(54) Method and apparatus for loading a java application program 



CM 
< 

CO 

o 



(57) An apparatus and method for loading software 
into a Java virtual machine ("JN/M") in a manner suited 
for real-time server applications. The software to be 
loaded is organized by Java package and class so that 
an application may be loaded in units of packages. Each 
package, and each class within a package, is loaded 
into the JVM in an order such that no package or class 
is loaded before the packages or classes upon which it 
depends. All software for an application is loaded into 
the JVM, and any compilation, optimization, or initializa- 
tion takes place, prior to execution of the application pro- 
gram, so that no delays are incurred during such exe- 
cution. Software loaded into the JVM, as well as at- 
tributes of that software, are identified. Versions of pack- 
ages are compared when loading the packages to en- 
sure compatibility An "image" of loaded software is cre- 
ated, which image may be reused by the JVM in order 
to restart an application rapidly following a failure. A 
loader environment within the JVM contains information 
about all loaded applications, packages, and classes, 
their attributes, and their interrelationships. 
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Description 
TECHNICAL FIELD 

[0001] The invention relates generally to Java appli- 
cation programs and. more particularly, to a method and 
apparatus for loading a Java application program to a 
Java virtual machine. 

BACKGROUND OF THE INVENTION 

[0002] Large-scale, complex computer systems are 
brought into use through integration of software pro- 
grams with a hardware platform. In many cases these 
large-scale systems require multiple configurations of 
software depending on the particular installation. Addi- 
tionally, many of these systems are real-time in nature, 
where the speed and, more importantly, the predictabil- 
ity of the system's performance is key. Lastly, many sys- 
tems are "servers" which means that they are expected 
to run continuously for long periods of time without in- 
terruption. 

[0003] A telecommunication network is an example of 
such a complex system. Telecommunication networks 
facilitate communications between a large number of 
public and private communications systems by provid- 
ing numerous functions such as switching, accounting, 
and time management. A telecommunications network 
provides these functions through network switches, or 
nodes, interconnected by links, or channels, of trans- 
mission media such as wire, fiber-optic cable, or radio 
waves. Some of the nodes are connected to one or more 
users. 

[0004] Modern telecommunication networks require 
complex, automated switching and, to that end, soft- 
ware programs are written to provide dependable per- 
formance and efficient use of resources, along with im- 
plementing sen/ice features and functions, such as Call 
Waiting, Caller ID, and the like. In such systems there 
may be different configurations depending on what 
types of transmission media are used, what types of us- 
ers are served, and what mix of features are purchased. 
In order to perform dependably, all software required for 
operation must be loaded into the system and initialized 
before the system begins its normal processing; other- 
wise, unpredictable variations in performance, and even 
unacceptable delays, might be experienced as needed 
software is identified, loaded, and initialized before 
processing can continue. 

[0005] A computer language for implementing soft- 
ware for such systems is "Java." Java was introduced 
by Sun Microsystems, Inc., of Palo Alto, California, and 
has been described as an object-oriented, distributed, 
interpreted, robust, secure, architecture-neutral, porta- 
ble, high-performance, multithreaded, and dynamic 
computer language. A key feature of Java with respect 
to this invention is its ability to load software dynamically. 
In many programming systems today, entire software 



applications are constructed (i.e.. software modules are 
linked together) as a unit. Java, however, allows soft- 
ware modules to be loaded and linked into a running 
program environment, known as a Java virtual machine 

5 (JVM). Thus, changing one module need not involve re- 
linking the entire application. Furthermore, applications 
may be extended by adding modules to the application 
without interrupting execution of the application. This 
capability makes Java very useful in the construction of 

10 server software applications. 

[0006] In the Java programming language, individual 
source files describing classes are compiled to produce 
class files, which are the most basic unit or software in- 
troduced into a system. As used herein, the term "class" 

15 refers to a generalized category that describes a group 
of more specific methods that can exist within it, and are 
comparable in concept to the types of "pigeonholes" 
used to organize information. The term "method" as 
used herein denotes a procedure or a function. Data and 

20 methods, taken together, generally serve to define the 
contents and capabilities of an object. 
[0007] Classes may be grouped into "packages." but 
packages are not presently a unit by which software 
code is loaded into a system. In a standard Java virtual 

2S machine (JVM), classes are typically loaded one at a 
time from class files, or perhaps from a compressed ar- 
chive containing a number of class files within it, possi- 
bly from unrelated packages. In accordance with a 
method of loading often referred to as "lazy loading," a 

30 class is not loaded until that class is needed by the JVM. 
Any necessary initialization for that class is similarly de- 
ferred for as long as possible. These techniques are 
suitable for software systems, such as "applets" in web 
browsers, that are primarily user-interactive. If all soft- 

35 ware that might possibly be needed were to be loaded 
and initialized before the applet could interact with the 
user, the user would experience an unacceptable delay. 
[0008] While lazy loading is appropriate for non-real 
time systems, such as that described above, lazy load- 

40 ing of software applications into the JVM Is usually not 
appropriate for real-time server applications. The unpre- 
dictable performance and unexpected latency associat- 
ed with lazy loading is often intensified because Java 
classes are commonly dependent on other classes. In 

45 many cases, in order to load one class, if other classes 
upon which the one class depends have not yet been 
loaded, the JVM will stop loading the one class while it 
attempts to load the other classes. 
[0009] In accordance with conventional JVM technol- 
ogy, application software is executed by first loading a 
"key" class and then executing a particular method of 
that class. In a stand-alone application, the key class Is 
a class with a "main" method which provides a starting 
point for the program. In an applet in a browser window. 

55 the key class is derived from the base applet class and 
is loaded, and a "start" method is called. In either the 
stand-alone application or the applet, once the key class 
is loaded, the remaining classes are identified and load- 
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ed as required. In some cases, security controls are 
used to constrain class loading. For example, an applet 
can only load classes from the same server from which 
the applet itself was initially loaded. The JVM does keep 
track of classes loaded, but does not keep track of pack- 
ages loaded, nor does it keep track of certain attributes 
of classes and packages that might be of interest 
[0010] For reasons of manageability, in a large-scale 
system having at least a single JVM. entire applications 
may be loaded more efficiently as collections of pack- 
ages, each of which packages encapsulates a collection 
of classes. This reduces, by an order of magnitude, the 
number of software objects that must be managed. Fur- 
thermore, if more than one application is loaded into a 
single JVM of the system, some packages may be 
shared between the applications and so need only be 
loaded once, reducing load times and saving memory 
space. In such a case, the package becomes the unit of 
software loaded into the system, rather than the individ- 
ual class file. It thus becomes more important to ensure 
that the package, as a concrete unit of software, can be 
immediately loaded from a package load file that con- 
tains all classes belonging to the package. 
[0011] Another feature of large-scale systems is that 
some software objects that make up the configuration 
of a running system may not have been developed, test- 
ed, and packaged at the same time. Instead, the objects 
may be of different vintages, and include some compo- 
nents that have remained unchanged for a long time, 
and some other components that continually change as 
the software is further developed and improved. As a 
result, it is often important to know what software objects 
are loaded into such a system, and to be able to ensure 
that only objects of compatible vintages are combined 
together. 

[0012] Accordingly, a continuing search has been di- 
rected to the development of methods for loading class- 
es without incurring unpredictable performance and un- 
expected latency associated with lazy loading, for load- 
ing packages only as needed to avoid increased load 
times and depleting memory unnecessarily, and for en- 
suring that software objects loaded in a system are of 
compatible vintages. 

SUMMARY OF THE INVENTION 

[0013] According to the present invention, Java soft- 
ware applications are loaded into a Java virtual machine 
(JVM) in a manner suited for real-time server applica- 
tions. The software to be loaded is organized by Java 
package and class so that an application may be loaded 
in units of packages. Each package, and each class 
within a package, is loaded into the JVM in an order such 
that no package or class is loaded before the packages 
or classes upon which it depends. All software for an 
application is loaded into the JVM, and any compilation, 
optimization, or initialization takes place, prior to execu- 
tion of the application program, so that no delays are 



incurred during such execution. Software loaded into 
the JVM, as well as attributes of that software, are iden- 
tified. Versions of packages are compared when loading 
the packages to ensure compatibility. An "image" of 

5 loaded software is created, which image may be reused 
by the JVM in order to restart an application rapidly fol- 
lowing a failure. A loader environment within the JVM 
contains information about all loaded applications, 
packages, and classes, their attributes, and their inter- 

10 relationships. 

[0014] In a first aspect of the present invention there 
is therefore provided a method for loading a Java appli- 
cation program onto a Java Virtual Machine ("JVM"), 
comprising the steps: of identifying package files re- 

is quired for operation of the application program, each of 
which package files comprises at least one class file; 
determining a package load order in which each respec- 
tive package file may be loaded before any package file 
is loaded that depends on the respective package file; 

20 determining a class load order in which each respective 
class file within each package file may be loaded before 
any class file is loaded that depends on the respective 
class file; and loading into the JVM the package files in 
the package load order, and the class files within each 

25 package file in the class load order 

[0015] In another aspect of the present invention 
there is provided a method for loading a Java application 
program to a Java Virtual Machine ("JVM") residing on 
a computer, the Java application program including a 

30 plurality of package files, each of which package files 
includes a plurality of class files, the method comprising: 

determining a class load order in which each re- 
spective class file within each package file may be 
3S loaded before any class file is loaded that depends 
on the respective class file; 

determining a package load order in which each re- 
spective package file may be loaded before any 
package file is loaded that depends on the respec- 

40 tive package file; 

storing the package load order in an application 
control file attached to the application program; 
reading the application control file into the JVM; and 
loading each package file into the JVM in the pack- 

45 age load order stored in the application control file, 
wherein the loading of each respective package file 
further comprises loading each class file of the re- 
spective package file into the JVM in the class load 
order. 

so 

[0016] In another aspect of the present invention 
there is provided a Java Virtual Machine ("JVM") oper- 
able on a computer and having a loader environment 
containing information about software objects which 
55 may be loaded onto the computer through the JVM, the 
loader environment comprising: 

an application data structure defined on an elec- 
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tronic memory of the computer, the application data 
structure being configured for receiving at least one 
application program; 

at least one package data structure defined on the 
electronic memory of the computer for identifying 
each respective package of the application data 
structure in such an order that, when the packages 
are loaded, no respective package is loaded before 
the packages upon which the respective package 
depends are loaded; and 

at least one class data structure defined on the elec- 
tronic memory of the computer for identifying each 
Java respective class data structure of the package 
data structure in such an order that, when the class 
data structures are loaded, no respective class data 
structures is loaded before the class data structures 
upon which the respective class data structure de- 
pends are loaded. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0017] For a more complete understanding of the 
present invention and the advantages thereof, refer- 
ence is now made to the following exemplary description 
taken in conjunction with the accompanying drawings, 
in which: 

FIGURE 1 is a block diagram illustrating a Java Vir- 
tual Machine ("JVM") embodying preferred features 
of the present invention; 

FIGURE 2 is a block diagram illustrating an appli- 
cation program to be loaded onto the JVM of FIG- 
URE 1 ; 

FIGURE 3 is a block diagram illustrating a loader 
environment within the JVM of FIGURE 1; and 
FIGURE 4 is a flow chart illustrating steps for imple- 
menting a preferred embodiment of the present in- 
vention. 

DETAILED DESCRIPTION OF A PREFERRED 
EMBODIMENT 

[0018] Referring to FIGURE 1 of the drawings, the ref- 
erence numeral 100 generally designates a Java Virtual 
Machine ("JVM") embodying features of the present in- 
vention. The JVM 100 may be implemented on any of a 
number of different computer platforms (not shown), 
such as a personal computer ("PC"), a Macintosh com- 
puter, a Unix workstation, or the like, running any of a 
number of different operating systems, such as Unix, 
Windows, MacOS, or the like. Such computer platforms 
and operating systems are considered to be well-known 
and will, therefore, not be described in further detail. 
[0019] The JVM 100 includes, within an electronic 
memory (not shown) of the computer, a main memory 
102 with a heap 104, and a JVM internal memory 106. 
The main memory 102 is an environment within which 
a Java application program 120. described further be- 



low, may be executed. The internal memory 106 is par- 
titioned to include a logical area of memory, designated 
as a loader environment 200, for loading the application 
program 1 20. The internal memory 1 05 is used to oper- 

s ate the JVM 100 and is not generally accessible to a 
Java program running in that JVM for safety and security 
reasons. The JVM 100 also includes a function compo- 
nent 110 for providing a garbage collection function 
110a, a system interface 110b, an execution engine 

10 1 1 0c (for executing instructions contained in methods of 
loaded classes), and the like, including threads (not 
shown) as defined by the architecture of the JVM 100. 
[0020] When the JVM 100 runs the Java application 
program 120, the memories 102 and 106 are used to 

^5 store Java components, such as bytecodes {i.e., meth- 
od bodies) and other infonnation extracted from a load- 
ed class file (described below), objects the program In- 
stantiates, parameters to Java methods, return values, 
local variables, Intenmediate results of computations, 

20 and the like. When a class instance or array is created 
in a running Java application program 120, the memory 
for the new class is allocated from the heap 104 portion 
of the main memory 1 02. 

[0021] An instruction set associated with the JVM 100 

25 includes an instruction for allocating memory on the 
heap 1 04 for a new object, but includes no instruction 
for freeing that memory. The JVM 100 is responsible for 
deciding whether and when to free memory occupied by 
objects that are no longer referenced by the running ap- 

30 plication. Generally, the garbage collection function 
110a of the JVM 100 is used to manage the heap 104. 
[0022] As discussed further below. FIGURE 2 exem- 
plifies the application program 120 as comprising data 
structures for an application control file 122, and three 

35 package files 1 24. The three package files 1 24 are sub- 
stantially similar to each other in a structural sense and, 
for the sake of conciseness, will therefore be described 
below representatively as the package file 124. Each 
package file 124 is depicted as comprising data struc- 

40 tures for three Java class files 128 which are substan- 
tially similar to each other in a structural sense and, for 
the sake of conciseness, will therefore described repre- 
sentatively as the class file 128. The package file 124 
may also contain a manifest 140. As indicated by the 

45 ellipses, the application program 120 may comprise 
more or less than three package files 1 24, and more or 
less than three class files 128 within each package file 
124. It should be noted though that the application pro- 
gram 120 is not a file, as such, containing within it the 

50 application control file 122, package files 124, though 
the application control file 1 22 does contain within it the 
identity of the package files included within the applica- 
tion program 120. The package files 124 do contain 
within them the class files 128. 

5S [0023] Each class file 128 contains everything the 
JVM 100 needs to know about one Java class or inter- 
face. This information is set out in a well-defined class 
file format to ensure that any Java class file can be load- 
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ed and correctly interpreted by any JVM 100, no matter 
what computer system produced the class file 1 28 or 
what system hosts the JVM 100. The class file 128 in- 
cludes a "magic number" (not shown), such as 
OxCAFEBABE. which identifies it as a Java file. Each 
class file also includes a version number (not shown), a 
constant pool 1 30, a methodjnfo portion 1 32, and an 
attributes portion 134, described below. Class files are 
considered to be well-known in the art and are de- 
scribed, for example, in a JVM specification entitled 
"The Java Virtual Machine" by Tim Lindholm and Frank 
Yellin (1997). ISBN 0-201-63452-X which is commer- 
cially available from Sun Microsystems, Inc. or at the 
web address http://www.aw.conn/cp/javaseries. 
[0024] The constant pool 130 contains constants, 
such as literal strings, final variable values, class 
names, method names, and the like, associated with the 
class or Interface defined by the file. It also contains 
names of other classes and methods referenced from 
within the class and its methods. Thus, by examining 
the class file 1 28, and particularly the constant pool 1 30, 
it is possible to identify all other classes required by the 
given class. 

[0025] The methodjnfo portion 132 contains infor- 
mation about a method (i.e., a procedure or a function), 
including the method name and descriptor, such as the 
return type, argument types, and the like; for non-ab- 
stract methods, a reference is also made to the byte- 
codes for the method. 

[0026] The attributes portion 1 34 provides general in- 
formation about the particular class or interface defined 
by the class file 1 28. such general information including 
(not shown) an attributes_count field, and a count of the 
number of attributejnfo tables appearing in the subse- 
quent attributes list. The first item in each attributes por- 
tion 134 is an index to the constant pool 130 of a 
CONSTANT_Utf8Jnfo table that gives the name of the 
attribute. Attributes come in many varieties, several of 
which are defined by the aforementioned JVM specifi- 
cation. In accordance with well-known rules, however, 
varieties of attributes may be created and placed into 
the class file 128. as described below. 
[0027] To build the application program 120. the 
source files to ail classes must be compiled. The source 
files may be compiled using an existing software devel- 
opment tool, such as the Java Development Kit (JDK), 
which is commercially available from Sun Microsys- 
tems, Inc. A "key" class of the application program 120 
must then be identified, and some method of the key 
class must be executed (possibly on a new instance ob- 
ject) to begin executing the application program. 
[0028] From the key class, a list of all classes required 
by the application program 120 may be generated by 
recursively calculating the transitive closure of the de- 
pendencies of the application program. This may be 
achieved, after identifying all the classes required by the 
key class, by recursively identifying the requirements of 
each of the additional classes, until no new classes are 



known to be required. Such a list of classes may be gen- 
erated using an order determination algorithm, such as 
a graph-walking algorithm or the like, well-known in the 
art. 

5 [0029] From the list of classes, a list of packages may 
be obtained, wherein each class is a member of one and 
only one package. Each package identified will in turn 
have a list of its constituent classes, which list is gener- 
ated by from the class files, or might be obtained from 

10 a database in an advanced software development envi- 
ronment or library system where the source files are 
maintained. The list of needed packages may be com- 
puted in a manner similar to that used for the classes, 
as described above. This list of packages is generated 
jn a certain order such that each package loads before 
packages that depend on it. and is stored in the appli- 
cation control file 122. The order is determined as a by- 
product of the computation of the list of needed packag- 
es by the aforementioned order determination algo- 

20 rithm. The application control file 122 may also identify 
the "key" class and possibly other attributes of the ap- 
plication program 1 20. such as the date of its construc- 
tion, security information, and the like. 
[0030] For each package required, a package, file 1 24 

2S is generated containing the class files 1 28 of the pack- 
age file 124, in such an order that each class file pre- 
cedes classes that may depend on it. The package file 
1 24 may also contain a manifest 1 40 providing security 
information for the classes and the like. The package 

30 load file may be in the format of a Java archive (JAR) 

file (not shown), or some other format. The JAR file for- > 
mat is well-known and is described in greater detail, for ; 
example, in a document entitled "jar-The Java Archive 
Tool" which is available at the web address http://www. 

35 javasoft.com/. This order may be determined as, a by- 
product of computing the class needs, as described i- . 
above with respect to the order determination algorithm, 
or nnay be computed anew through the same or a similar 
algorithm, applied only to the classes which constitute 

40 the package. It should be noted, howeve r, that packages 
which may be part of a "standard library" associated with 
the JVM 100 need not have package files created for 
them; it is assumed that such packages are resident with 
the JVM and do not require loading to the JVM through 

45 this method. 

[0031] As mentioned above with respect to FIGURE 
1. the JVM internal memory 106 includes a logical area 
of memory, designated as a loader environment 200, for 
loading the application program 120. The application 

50 program 1 20 Includes at least one package, depicted in 
FIGURE 2 as the package files 1 24, each of which have 
at least one type, i.e., at least one class file 128 and 
corresponding interface (not shown) having fully quali- 
fied names. The loader environment 200 catalogs each 

55 application, package, and class loaded, along with their 
relationships and other attributes. The relationships de- 
fine, for example, which objects {e.g., application pro- 
gram 120. package files 124, class files 128. and the 
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like) contain or are contained by which other objects, 
which objects require or are required by which other ob- 
jects, and the like. Attributes for packages and classes 
include author, compile date, package build date, ver- 
sion of the package or class, version(s) of requ ired pack- 
ages or classes that are known to be connpatible (or in- 
compatible), and the like. 

[0032] Referring back to FIGURE 1, the loader envi- 
ronment 200 is configured for storing metadata describ- 
ing attributes of the application programs 120 (FIG. 2), 
such as the version number, compile date, and the like, 
and attributes of the classes and packages loaded as 
part of those application programs. When the JVM 100 
loads a Java application program 120, the JVM 100 
parses attribute information from the application control 
file 122 (FIG. 2). Such attributes for the packages may 
be stored within the package file 1 24 within the manifest 
140 (FIG. 2). (e.g., in the JAR file format described in 
the aforementioned JAR specification). For each class, 
attribute information is contained in the class file 128 
(FIG. 2) as described above. Effectively, the JVM 100 
builds within the loader environment 200 a collection of 
information about all loaded software, and makes such 
infonmation available to programs running on the JVM 
via an application programming interface (API) in a man- 
ner well-known in the art. 

[0033] Such a collection of information in the loader 
environment 200 is exemplified in FIGURE 3 as com- 
prising a list 304 of applications 304a, 304b, and 304c, 
a list 306 of packages 306a, 306b, 306c, and 306d, and 
a list 308 of classes 308a, 308b, 303c, and 308d effec- 
tive as data structures for cataloging the installed soft- 
ware of the loader environment 200. The number of ap- 
plications, packages, and classes making up the loader 
environment 200 may vary from the number shown in 
FIG. 3. Relationships are also cataloged, as indicated 
by the arrows 310, such as between the application A, 
304a and the package P-, 306a. The loader environment 
200 also contains a JVM software environment 302 
(FIG. 4), which is part of the JVM 100. The software en- 
vironment 302 contains such data as the methods of the 
classes, their types and arguments, and the like, as well 
as by-products such as native code generated by a just- 
in-time (JIT) compiler, and the like, stored in a manner 
well-known to the art. The class elements 308a-308d in 
the loader environment 200 may refer back to the JVM 
software environment 302. 

[0034] The size of the loader environment 200 need 
not be fixed. As the Java application program 1 20 runs, 
the JVM 100 can expand and contract the loader envi- 
ronment 200 to fit the needs of the application. Gener- 
ally, users or programmers may specify an initial size for 
the loader environment 200, as well as a maximum or 
minimum size. 

[0035] FIGURE 4 is a flow chart of steps implemented 
in the operation of loading the Java software packages 
124 of an application program 120 in accordance with 
a preferred operating methodology of the present inven- 



tion. Accordingly, in step 400, given the application 120 
to be loaded to the JVM 110, a list of packages that are 
required for the application is derived. The package list 
may be derived using any available technique, such as, 
5 for example, by using a configuration management sys- 
tem (not shown). 

[0036] In step 402, a class load order is determined 
first within each package for all of the class files 128 
within that respective package, so that when each class 

10 is loaded, any classes on which that respective class 
depends will have been previously loaded. Similarly, a 
package load order is detemnined for each of the pack- 
age files 124, as described above, so that when each 
package is loaded, any packages on which that respec- 

75 tive package depends will have been previously loaded. 
[0037] In step 404, any metadata associated with a 
class is incorporated into its respective class file 128. 
The class file 1 28 and any metadata associated with a 
package, including any security information, are then in- 

20 corporated into a respective package file 124. These 
package files 124 may then be placed in some reposi- 
tory, such as a disk directory, web site, database, or the 
like, from which they may be loaded when required. 
[0038] In step 406, the application control file 1 22 for 

25 the entire application program 1 20 is generated. The ap- 
plication control file 122 includes a list of the package 
files 124 in the order that they are to be loaded into the 
application program 1 20, and may also include other in- 
formation, such as a "key" class, security information, 

30 and the like. The application control file 122 is also 
stored so that It may be used to load the application pro- 
gram 120; however, it need not be stored together with 
the package files. 

[0039] In step 408. operation of the Java virtual ma- 
35 chine 100 is initiated. The application program 120 to 
be loaded may be passed as a parameter to the JVM 
100 by some means dependent on the operating sys- 
tem, or the JVM may wait for a command to load that is 
supplied externally, e.g., through a network interface. 
40 [0040] In step 41 0, the JVM 1 00 reads the application 
control file 122, extracting information stored therein, in- 
cluding, in particular, the list of package files 1 24 making 
up the application program 120. 

[0041] In step 41 2, the JVM commences to load and 
45 process the application 120 beginning with the first 
package file 124 on the list extracted in step 410, i.e., 
the package file 124 that does not depend on any other 
listed package file. Prior to actually loading the package, 
the JVM 1 00 first looks up the respective package in the 
50 loader environment 200 to determine whether the pack- 
age has been previously loaded (such as, for example, 
in a standard library which may have been previously 
loaded). If the current package has not been loaded, 
then the JVM 100 verifies that any other packages on 
55 which the current package depends are loaded and are 
compatible. If such other packages are not loaded or 
are incompatible, then the JVM 100 stops loading and 
gives an error message, e.g., by displaying a message 
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on a terminal screen (not shown), printing the message 
on a printer (not shown), or the like. Otherwise, if such 
other packages are baded and are compatible with the 
package being loaded, then the JVM 100 opens the 
package file 124. by reading a disk file (not shown), by 
opening a network connection to download the package 
file 1 24 trom another machine (not shown), by acquiring 
it from a database (not shown) , or the like. The JVM 
100 updates its loader environment 200 with data from 
the package file 124, which data represents attributes 
of the package, and of the relationship of the package 
being loaded to other packages. 
[0042] In step 414. the JVM loads the first class file 
128 from the package file 124 being loaded, decom- 
presses it as necessary, verifies any security informa- 
tion, and links it into the JVM loader environment 200. 
This method by which class files 1 28 are loaded into the 
JVM, such as the JVM 100, Is considered to be well- 
known in the art and will therefore not be described fur- 
ther. Additionally, attributes of the class, as well as its 
relationship to the package in which it is contained, are 
entered into the loader environment 200. 
[0043] In step 416, if there are additional class files 
128 in the package file 1 24 to load, execution proceeds 
to step 41 8; otherwise, execution proceeds to step 420. 
At step 418, the next class file 128 in the package file 
1 24 being loaded is loaded in the manner described with 
respect to step 414, and the loader environment 200 is 
updated. Upon loading the next class file 128. execution 
returns to step 416. 

[0044] In step 420, any additional processing, such as 
pre-compilation to native code, optimization, execution 
of the initialization routines for the classes, or the like, 
required for the classes 128 loaded from the package 
file 124 is performed in a manner well-known in the art. 
[0045] In step 422, a determination is made whether 
there are additional package files 124 to load in the ap- 
plication program 120. If it is determined that there are 
additional package files 124 to load in the application 
program 120, then execution proceeds to step 424 
wherein the next package in the list of packages extract- 
ed in step 410 is loaded. Following step 424, execution 
returns to step 414. If, in step 422, it is determined that 
there are no additional package files 124 to load in the 
application program 120, then execution proceeds to 
step 426. wherein execution of the application program 
120 on the JVM 100 commences in a manner well- 
known in the art. 

[0046] By the use of the present invention, a Java soft- 
ware application program may be efficiently preloaded 
onto the JVM 1 00 to thereby eliminate "lazy loading" and 
enhance the performance of real-time systems. The 
present invention also provides a basis for determining 
what software is loaded onto a running, as the loader 
environment 200 contains a list of the running applica- 
tion(s), packages, classes, their attributes, and their in- 
terrelationships. A JVM 100 using the method of this in- 
vention may provide an application programming inter- 



face (API) or some other method by which a program 
running on such a JVM 100 may query the loader envi- 
ronment 200 and inspect the information stored therein, 
or by which an external program may query the JVM for 

5 that information, or both. 

[0047] It is understood that the present invention can 
take many forms and embodiments. Accordingly, sev- 
eral variations may be made in the foregoing without de- 
parting from the scope of the invention; for example, 

to more than one application may be loaded into a single 
JVM 100. In another example, an image of the loaded 
application may be stored in a non-volatile medium. 
That is, the state of the loader environment 200, includ- 
ing all classes, packages, and information about the 

IS classes and packages, may be written out to a non-vol- 
atile medium, such as a hard disk file. This information 
would include the code (including compiled or optimized 
code) for methods of the classes so written out. Then, 
in order to restart the JVM 1 00 with that same software 

20 at a later time, the disk file may be simply read in, allow- 
ing the JVM to bypass the steps 400-418 and 422-424 
in the above description of the flow chart shown in FIG- 
URE 4. Instead, the JVM 100 would need only to reini- 
tialize each class (thus recreating any initial data in the 

2S heap 104) and commence program execution (steps 
420 and 426, respectively). Such a technique would 
greatly enhance the speed with which a JVM 100 could 
be restarted after a failure, such as a hardware crash. 
In still another example, the JVM 100 may provide an 

30 interface, such as a network interface, an inter-process 
communication interface configured for a particular op- 
erating system, or the like, through which interface an 
external program may inspect the data structures of the 
application program, packages, and classes loaded in 

3S the JVM. 

[0048] Having thus described the present invention by 
reference to certain of its preferred embodiments, it is 
noted that the embodiments disclosed are illustrative 
rather than limiting in nature and that a wide range of 
40 variations, modifications, changes, and substitutions 
are contemplated in the foregoing disclosure and, in 
some instances, some features of the present invention 
may be employed without a corresponding use of the 
other features. 

45 

Claims 

1. A method for loading a Java application program 
50 ontoa Java Virtual Machine ("JVM"), comprising the 
steps of: 

identifying package files required for operation 
of the application program, each of which pack- 
55 age files comprises at least one class file; 

determining a package load order in which 
each resjDective package file may be loaded be- 
fore any package file is loaded that depends on 
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the respective package file; 
determining a class load order in which each 
respective class file within each package file 
nnay be loaded before any class file is loaded 
that depends on the respective class file; and 
loading into the JVM the package files in the 
package load order, and the class files within 
each package file in the class load order. 



3. The method of Claim 1 or 2. wherein the step of de- 
ternnining a class load order further comprises re- 
cursively calculating a transitive closure of depend- 
encies of the class files. 



identifying all class files required by the key class, 
and recursively identifying the requirements of each 
of the class files, until no new class files are known 
to be required. 

6. The method of any preceding claim wherein the 
step of loading further comprises, for each respec- 
tive package file, the steps of determining whether 
the respective package file has previously been 



9. The method of any preceding claim, wherein the 



JVM includes a loader environment, and the step of 
loading package files into the JVM further compris- 
es loading each package file into the loader envi- 
ronment of the JVM. 

5 

10. The method of Claim 9, further comprising: 
storing in non-volatile memory or other media 

the contents of a loader environment, such that the 
contents may be retrieved by a fresh invocation of 
the JVM in order to execute the program without in- 
dividually reloading each application, package file, 
and class file. 

11. The method of any preceding claim, further com- 
?5 prising the step of generating with respect to each 

package file a package load file identifying in the 
class load order the class files contained within the 
respective package file. 

12. The method of any preceding claim, further com- 
prising the steps of generating an application con- 
trol file identifying the package files in the package 
load order, and reading the application control file 
into the JVM; and the step of loading further com- 
prises loading each package file into the JVM in the 
package load order stored in the application control 
file, wherein the loading of each respective package 
file further comprises loading each class file of the 
respective package file into the JVM in the class 
load order. 

13. A method for loading a Java application program to 
a Java Virtual Machine ("JVM") residing on a com- 
puter, the Java application program including a plu- 

35 rality of package files, each of which package files 
includes a plurality of class files, the method com- 
prising: 

determining a class load order in which each 
respective class file within each package file 
may be loaded before any class file Is loaded 
that depends on the respective class file; 
determining a package load order in which 
each respective package file may be loaded be- 
fore any package file is loaded that depends on 
the respective package file; 
storing the package load order in an application 
control rde attached to the application program; 
reading the application control file into the JVM; 
and 

loading each package file into the JVM in the 
package load order stored in the application 
control file, wherein the loading of each respec- 
tive package file further comprises loading 
each class file of the respective package file in- 
to the JVM in the class load order. 

14. The method of Claim 13, wherein the step loading 



2. The method of Claim 1 wherein the step of deter- io 
mining a package load order further comprises re- 
cursively calculating a transitive closure of depend- 
encies of the package files. 



4. The method of Claim 1 , 2 or 3 wherein the applica- 
tion program contains a key class, and the step of 
determining a package load order further comprises 
identifying all class files required by the key class, 
and recursively identifying requirements of each of 
the class files, until no new class files are known to 
be required. 

5. The method of any preceding claim, wherein the ap- 
plication program contains a key class, and the step 
of determining a class load order further comprises 30 



loaded; and upon a determination that the respec- 
five package file has not been loaded, loading the 
respective package file. 

7. The method of any preceding claim, wherein the 
step of loading further comprises at least one of the 45 
steps of: 

compiling all loaded class files; 
optimizing all loaded class files; and 
initializing all loaded class files. 50 

8. The method of any preceding claim, wherein the 
step of loading includes comparing versions of load- 
ed package files with requirements of package files 
to be loaded, to determine version compatibility be- ss 
tween package files. 
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each respective package file further comprises 
compiling the respective package file. 

15. The method of Claim 13 or 14, wherein the step 
loading each respective package file further com- 
prises initializing the respective package file. 

16. The method of Claim 13, 14 or 15. wherein the step 
of loading each respective package file further com- 
prises optimizing the respective package file. 

17. The method of any one of Claims 13 to 16. wherein 
the step of determining a class load order further 
comprises recursively calculating the transitive clo- 
sure of the dependencies of the application pro- 
gram. 

1 8. The method of any one ot Claims 1 3 to 1 7, wherein 
the step of determining a package load order further 
comprises recursively calculating the transitive clo- 
sure of the dependencies of the application pro- 
gram. 

19. The method of any one of Claims 1 3 to 1 8, wherein 
the JVM includes a loader environment, and step of 
loading each package file into the JVM further com- 
prises loading each package file into the loader en- 
vironment of the JVM. 

20. The method of any one of Claims 13 to 19, wherein 
the JVM includes a loader environment containing 
information about software objects loaded on the 
computer through the JVM, and step of loading 
each package file into the JVM further comprises 
loading each package file into the loader environ- 
ment of the JVM- 

21 . A Java Virtual Machine ("JVM") operable on a com- 
puter and having a loader environment containing 
information about software objects which may be 
loaded onto the computer through the JVM, the 
loader environment comprising: 

an application data structure defined on an 
electronic memory ot the computer, the appli- 
cation data structure being configured for re- 
ceiving at least one application program; 
at least one package data structure defined on 
the electronic memory of the computer for iden- 
tifying each respective package of the applica- 
tion data structure in such an order that, when 
the packages are loaded, no respective pack- 
age is loaded before the packages upon which 
the respective package depends are loaded; 
and 

at least one class data structure defined on the 
electronic memory of the computer for identify- 
ing each Java respective class data structure 



of the package data structure in such an order 
that, when the class data structures are loaded, 
no respective class data structures is loaded 
before the class data structures upon which the 
5 respective class data structure depends are 

loaded. 

22. The JVM of Claim 21 , wherein the application data 
structure, the package data structure, and the class 

10 data structure include data structures which define 
relationships between application programs, pack- 
age files, and class data structures. 

23. The JVM of Claim 21 or 22, wherein the application 
IS data structure further comprises attributes belong- 
ing to applications loaded onto the JVM, the pack- 
age data structure further comprises attributes be- 
longing to packages loaded onto the JVM package 
data structure, and the class data structure further 

20 comprises attributes belonging to class data struc- 
tures loaded onto the JVM. 

24. The JVM of Claim 21, 22 or 23, further comprising 
a program running in the JVM configured for in- 

25 specting the application data structures, the pack- 
age data structures, and the class data structures 
in the JVM. 

25. The JVM of any one of claims 21 to 24, further com- 
30 prising an interface between the JVM and an exter- 
nal program through which the external program 
may inspect the application data structures, the 
package data structures, and the class data struc- 
tures in the JVM. 

35 

26. A computer program element comprising computer 
program code means to make a computer execute 
procedure to perform the method of any one of 
claims 1 to 20. 

40 

27. The computer program element of claim 26, embod- 
ied on a computer readable medium. 

28. Electronic signals representing instructions or 
45 statements to make a computer execute procedure 

to perform the steps of any one of Claims 1 to 20, 
wherein the electronic signals are adapted to sup- 
port transmission thereof over a communication 
network. 

so 
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